Package constants#8916
Conversation
…rong impure cache usage
|
Are comments supported for constants? I didn't see this in the documentation. Comments are simply supported for packaged procedures and functions. It would make sense to do the same for constants (and any package objects, for that matter). |
No, I didn't plan to implement comments, but I think it's possible. I will take a look |
|
I think the |
I add a list with all valid constant operations. |
|
I was going to test if a constant with exception could be created (it should not) and an assert happened: |
Hmm, it looks like the pool shouldn't be deleted. I fixed it |
It should, but not always. If exception is raised from |
Thanks for the explanation. I tried calling |
I'd expect something like this: catch (const Exception&)
{
if (handmadeStmt)
handmadeStmt->release(tdbb);
else
deletePool(csb_pool);
throw;
} |
Thank you. This works great |
|
|
||
| ITransaction* local_trans = tdgbl->global_trans ? tdgbl->global_trans : gds_trans; | ||
|
|
||
| STORE (TRANSACTION_HANDLE local_trans |
There was a problem hiding this comment.
Conditional store of value in fields without set they .NULL = TRUE before will make them always non-null, with garbage when the conditional paths are not executed.
There was a problem hiding this comment.
I'm really confused about the NULL spcificatin. Many places in the code explicitly set <field>.NULL = FALSE, so I assumed it was TRUE by default. But, it seems like I was wrong
Am I understanding the rules correctly:
- If NULL isn't explicitly specified, NULL=FALSE is set;
- If NULL is explicitly present but not specified, NULL=FALSE is set.
…and hash counter in Resources
|
System package constants are not available. select
RDB$BLOB_UTIL.FROM_BEGIN
from RDB$DATABASE;The reason may be that the select
P.RDB$USER,
P.RDB$PRIVILEGE
from RDB$USER_PRIVILEGES P
where p.RDB$RELATION_NAME = 'RDB$BLOB_UTIL';There should be two more entries here, in theory. |
...and an error message explicitly mentioning missing rights. |
It's not necessarily a privilege issue. However, according to the description, constants require the |
The RDB$BLOB_UTIL is in the SYSTEM schema. Therefore, it must be explicitly present in the query: select
SYSTEM.RDB$BLOB_UTIL.FROM_BEGIN
from RDB$DATABASE; |
|
|
This works, but I agree with @aafemt comment, the |
It looks like I misunderstood the code and used the wrong schema search function.. I will create a PR with a fix |
|
And the second question: I'm creating a constant in a package, and for some reason I can't see the source code for its initialization expression. set term ^;
recreate package p_cosnt_test
as
begin
constant SOME_CONST INTEGER = 1;
end^
recreate package body p_cosnt_test
as
begin
end^
set term ;^
select
RDB$CONSTANT_NAME,
RDB$CONSTANT_BLR,
RDB$CONSTANT_SOURCE
from RDB$CONSTANTS
WHERE RDB$PACKAGE_NAME = 'P_COSNT_TEST'
AND RDB$SCHEMA_NAME = 'PUBLIC';Why is |
Good question. It looks like I lost RDB$CONSTANT_SOURCE storing functional during the Metacache merge. I'll add this to the pull request. |
So, |
No, the usage is necessary, but I'm not sure how it should be provided to SYSTEM packages. Database: employee, User: A
SQL> select RDB$BLOB_UTIL.FROM_END from rdb$database;
Statement failed, SQLSTATE = 28000
no permission for USAGE access to PACKAGE "SYSTEM"."RDB$BLOB_UTIL"
-Effective user is A |
|
The USAGE privilege is indeed necessary. The only thing I'd like to point out is that privileges aren't checked for SYSDBA anyway, so they don't need to be created. However, I would prefer consistent behavior for all privilege types. That is, if the EXECUTE privilege is created for SYSDBA for each package, then the same should be true for USAGE. |
I added USAGE privilage for all system packages. |
10 participants
Package Constants
This PR adds a new database object - Package Constant (#1036). It is a constant value located in a package header (public visibility) or a package body (private visibility). See README.packages.txt for more information.
SYNTAX
Creation:
<constant_expr>is an expression that remains unchanged after recompilation.Package constants can be queried using the expression
<package_name>.<consatnt_name>outside the package (<consatnt_name> must be a public constant) and using the expression<consatnt_name>inside the package.To query a constant, the user/role must have USAGE permission on the package.
Other SQL extensions:
Usage examples:
System Constants
As an exmaple, 3 consatnts have been added to the RDB$BLOB_UTIL package
System metadata changes
New system table - RDB$CONSTANTS
A new field has been added to
RDB$PACKAGES-RDB$PACKAGE_IDNew indexes:
Implementation
Packages have been added to the metacaching system. Since it relies heavily on identifiers, a new ID field (
RDB$PACKAGE_ID) has been added to theRDB$PACKAGEStable. Constants are stored as an array in the package metacaching object, with a constant_name-to-array_id mapping.There are also two important points: